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(54) Device dependent rendering of characters 

(57) A method for creating anti-aliased characters 
on a computer output device includes the steps of gen- 
erating a call from a client process for a character to be 
rendered, selecting a best alignment grid from a set of 
alignment grids associated with the device grid, render- 
ing the character at a high resolution, and aligning 
stems of the character with an alignment grid corre- 
sponding to the resolution of an output device. The step 
of aligning the high resolution rendered stems to the 
alignment grid provides for an anti-aliased output with 
balanced stems. 
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Description 

[0001] This invention relates generally to computer systems, and more particularly to the rendering of characters to 
be displayed on computer output devices. 

5 

Background of the Invention 

[0002] Computer systems typically include some form of visual output device. For example, in Fig. 1 , a prior art 
computer system 1 0 includes a computer 1 2, a keyboard 1 4, a disk storage unit 1 6, a video display 1 8, and a printer 20. 
10 [0003] Computer 12 includes a central processing unit (CPU) 22, read only memory (ROM) 24, random access 
memory (RAM) 26, and input/output (I/O) 28. The various components 22-28 of the computer 12 are coupled by a bus 
system 30. As will be appreciated by those skilled in the art, the representation of the computer 12 has been highly sim- 
plified for the purposes of this discussion, but includes the fundamental components of a computer and their intercon- 
nections. 

is [0004] Devices such as keyboard 14, disk, storage 16, video display 18, and printer 20 are often referred to as 
"peripheral" devices. When coupled to the computer 12 they become part of computer system 10. Some peripheral 
devices are primarily for inputting information to the computer 12, other peripheral devices are used for outputting infor- 
mation from the computer 12, and some computer peripherals arc used for both inputting and outputting information. 
[0005] Video display 18 and printer 20 are common output devices for the computer 12. Such output devices typi- 

20 cally form temporary or permanent images to convey information to a user of computer system 10. For example, video 
display 18 includes a screen that can display character, graphical, and other types of images. 

[0006] A number of problems arise when displaying characters on a computer output device. The term "character", 
as used herein, is not limited to alphanumeric characters, but includes any form of character, number, symbol, or other 
coded device that can be represented or displayed on a computer output device. Some problems relate to the resolution 

25 of the output device, and other problems relate to human visual perception. "Resolution", as it is used herein, refers to 
the size of individual pixels of a computer output device, and the spacing between the pixels of the output device. 
[0007] The problems inherent in character imaging tend to be more pronounced for small characters than for larger 
characters. This is because small characters are made up of fewer pixels and, therefore, even a distortion of a few pixels 
is readily apparent in the smaller characters. Some of the distortions that may occur, particularly in these smaller char- 

30 acters, are: unbalanced "stem" widths, thin feature disconnection, over/under filling, and inaccurate weighting. One of 
the most noticeable of these defects is unbalanced stem widths, where vertical and horizontal strokes of characters may 
be of varying widths due to the character rendering process. Another very noticeable defect is the inaccurate weighting 
effect of small characters due to a quantization effect. Adding a pixel (the "quantum") to a character stem that is only a 
few pixels wide can distort the "weight" given to that character, e.g. it may appear to be "bold" even when it is a normal 

35 weight character. 

[0008] In Fig. 2A, the prior art problem of unbalanced stem widths is illustrated. In this instance, a lower case letter 
"m" is shown superimposed over a high-resolution grid 32 both in an outline form 34, and a "bitmap" form 36. "Bitmap- 
refers to a one-to-one mapping between data stored in the memory of the computer 12 and an image of the character 
to be displayed, i.e. each pixel of the output device corresponds to a bit of information stored in the computer. The out- 
40 line 34 is typically provided by a parsed font program such as described in Adobe Type I format, Version 1.1, available 
from Adobe Systems, Inc. of San Jose, California, often referred to as the "Black Book" due to the color of its cover. 
Character outline 34 is converted or "rendered" into the bitmap 36 by a rendering program or "renderer" available from 
a variety of sources, including Adobe Systems, Inc. 

[0009] In Fig. 2A, the letter "m" includes some distortion that is attributable to the conversion from font outline 34 to 
45 bitmap 36 form. In particular, the three vertical legs or "stems" of the letter "m" are of different widths. As noted, the left 
stem 38a is two pixels wide, the middle stem 38b is one pixel wide, and the right stem 38c is two pixels wide. 
[0010] While characters are often rendered on a high-resolution grid as illustrated in Fig. 2A, they must be con- 
verted into a "coarse grid" representation before they can be displayed on the output device. The resolution of the 
coarse grid corresponds to the resolution of the output device. 
so [001 1] In Fig. 2B, the conversion from a high-resolution grid to a coarse grid permits the renderer to re-balance the 
stems. More particularly, the system uses "hints" provided by the parsed font program to stretch and then align the 
sterns of the character to the coarse grid. As noted, in Fig. 2B, the stems 40a, 40b, and 40c are all the same width and, 
therefore, the unbalanced stem problem can be resolved for black-and-white types of output devices. 
[0012] While the prior art has solved the problem of unbalanced stem widths for black and white output devices, the 
55 problem has re-emerged for greyscale and color output devices. Some output devices use a technique known as "anti- 
aliasing" in order to provide the illusion of smoother curves and less jagged diagonal lines. This is accomplished by var- 
ying greyscale or color values of the coarse grid. However, this manipulation can re-introduce the problem of unbal- 
anced stem widths to anti-aliased characters. 
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[001 3] In Fig. 2C, the lower case letter "m" is shown against a coarse grid 42 and corresponding high-resolution grid 
44. The high-resolution grid 44 is shown in only one of the cells of the coarse grid 42 so as not to confuse the drawings, 
although it will be appreciated that the high-resolution grid 44 is associated with all the cells of the coarse grid 42. The 
coarse grid and the high-resolution grid are related as follows. If the output device has 2 n +1 greyscale values, each 

5 "cell" 46 of the coarse grid 42 will have 2 n pixels 48. To provide a more concrete example, if 1 7 greyscale levels are pro- 
vided from pure white to pure black, then 2 4 or 16 pixels of the high-resolution grid are in each cell of the coarse grid 
42. This means that the resolution of the high-resolution grid 44 is four times the resolution of the coarse grid 42. As 
before, the font outline 50 for the letter "m" is obtained, and a bitmap 52 is developed at the resolution of the high-res- 
olution grid from the font outline 50 by the renderer. 

io [0014] In Fig. 2D, the bitmap 52 has been converted into a greyscale "pixel map" which can be sent to the output 
device. The conversion is usually accomplished in a straightforward fashion. The number of pixels for a particular cell 
are counted, and this number is mapped to the greyscale level for that cell. Therefore, cells having more pixels will cor- 
respond to a darker greyscale value than cells having fewer pixels. This technique, referred to as "anti-aliasing", greatly 
smooths the appearance of curves and reduces the jaggedness of diagonal lines, as is well known to those skilled in 

is the art. 

[0015] As used herein, a "Pixel map" is much like a "bitmap" except that multiple values are stored in the memory 
of the computer system 12 which correspond to each pixel of the output device. For example, for each pixel on a grey- 
scale or color video monitor, multiple sub-pixels can be defined each including a numeric value that is stored on the 
computer. 

20 [0016] However, as seen in Fig. 2D, the unbalanced stem problem has reoccurred as a result of the application of 
the "anti-aliasing" process. More particularly, stem 54a appears to be two pixels wide, while stems 54b and 54c appear 
to be about one pixel wide. Again, this stem unbalance phenomenon is quite apparent in small characters and reduces 
the quality of the output image. 

[0017] While this discussion has centered on vertical stems, that the problem is equally apparent with horizontal 
25 stems. For example, while the example of the lower case "m" was given, this stem unbalancing problem is also apparent 
on letters such as an upper case M E." Furthermore; both vertical and horizontal "stems" or segments can be found in a 
single letter, such as the letter "o", which has two vertical side segments or stems, and two horizontal top and bottom 
segments or stems. 

[0018] Some attempt has been made by output device manufacturers to enhance the image provided to the output 
so device as a bitmap or a pixel map. For example, certain Hewlett-Packard Company printers provide "image enhance- 
ment" which attempts to smooth "jagged" diagonal lines and to smooth curves. While generally useful, such post-ren- 
dering image enhancement mechanisms are not completely successful because the information that was used to 
create the bitmap or pixel map (e.g. the font outline) is not available to the output device after. the render process has 
been applied. Therefore, post-rendering image enhancement cannot correct problems such as unbalanced stem 
35 widths, etc. 

[0019] Another technique for enhancing the image provided to the output device includes aligning stems on pixel 
boundaries and is described in co-pending United States patent application serial number 08/547, 562, filed October 
23, 1995, entitled "Method and Apparatus for Rendering Characters," to Terence Dowling, assigned to Adobe Systems, 
Inc of San Jose, California, the contents of which are expressly incorporated herein by reference. This technique does 
40 not suffer from the limitations provided by post-render solutions. However, the technique described in the Dowiing appli- 
cation was limited in that the stem alignment was fixed to a single device grid and therefore to the device grid bounda- 
ries (pixel boundaries) defined therein. 

[0020] Certain output devices, such as LCDs support sub-pixel addressing. Sub-pixel, as used herein, refers to a 
pixel component that is independently addressable in the output device. For example, in a conventional RGB color out- 

45 put LCD device, a single pixel includes three components, or sub-pixels, a red component, a green component and a 
blue component. Each of the three sub-pixels are independently addressable for each pixel, that is, each individual 
component can have a value set, the combination of which produce the color perceived by the user for a particular pixel 
location. In a conventional RGB LCD output device, the sub-pixels include a geometry, the sub-pixel geometry, that 
defines an physical arrangement of the sub-pixels on the output device. In one conventional RGB LCD output device, 

50 each sub-pixel is of the form of a color bar, and the bars are arranged as a horizontal row. Depending on the manufac- 
turer of the output device, the ordering of the color bars may vary from device to device. For example, in a Colorbook 
device produced by Gateway Computers or a Inspiron 7000 device produced by Dell Computers, the sub-pixel geome- 
try includes an arrangement of color bars in a horizontal row. Other geometries are possible including a closely packed 
hexagonal arrangement. 

55 

Summary 

[0021] The present invention provides a method for precisely placing stems of a character and increasing the effec- 
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tive horizontal resolution of a output device by a factor in at least one dimension. In a conventional RGB LCD device, 
the effective resolution can be increased by an order of magnitude of three without increasing the cost/complexity of the 
output device. 

[0022] In one aspect, the invention provides a computer-implemented method for processing a character for display 

5 on a raster output device where the output device has a resolution and a set of pixels defining a device grid. The method 
includes evaluating a plurality of alignment grids and selecting a best alignment grid for a stem of the character where 
the plurality of alignment grids from a set of grids. Each alignment grid in the set being is similar to the device grid but 
shifted by a phase difference equal to a sub-pixel dimension. The process includes rendering the character at a reso- 
lution higher than the resolution of the output device including aligning the stem using the selected alignment grid to a 

10 sub-pixe! boundary and down sampling the rendered character to the resolution of the output device. 

[0023] Aspects of the invention may include one or more of the following features. The character is created at a type 
size by a font having font metrics including hinting information defining a center of a stem. The step of evaluating 
includes laying down the character and determining an alignment grid that best aligns the center of the stem to a sub- 
pixel boundary. The method can further include receiving sub-pixel geometry information for the output device defining 

is a geometry of the addressable sub-pixels for each pixel of the output device. The step of aligning the character can 
include using the sub-pixel geometry information to determine which sub-pixels of which pixels to illuminate when the 
character is not aligned to a pixel boundary. The step of down sampling can include receiving device specific data 
derived specifically for the output device where the device specific data includes a plurality of functions, one for each 
color plane used by the output device. The method can include determining an intensity for each sub-pixel of a pixel in 

20 the selected alignment grid using the device specific data to derive intensity data specifically for the output device. The 
sub-pixel dimension can be a sub-pixel width, height or height and width. 

[0024] In another aspect, the invention provides a computer-implemented method for processing a character for 
display on a raster output device having an resolution defined by a set of output pixel positions. The method includes 
aligning a stem of the character to a best sub-pixel boundary, rendering the character at a resolution higher than the 

25 resolution of the raster output device and down sampling the aligned character to the raster output device resolution. 
[0025] Aspects of the invention can include one or more of the following advantages. An advantage of the present 
invention is that the technique can be used to smooth curves and prevent jagged diagonal lines without introducing cer- 
tain distortions into the image of the character being displayed while providing up to a threefold increase in the resolu- 
tion in one dimension for an RGB output device. The invention accomplishes this task by aligning the high-resolution 

30 bitmap of the character to a sub-pixel boundary of an alignment grid and then mapping the alignment grid to the coarse 
grid during the rendering process. 

[0026] These and other advantages of the present invention will become apparent upon reading the following 
detailed descriptions and studying the various figures of the drawings. 

35 Brief Description of the Drawings 

[0027] 

Fig. 1 is a block diagram of typical prior art computer system, which is also a suitable host for the method and appa- 
40 ratus of the present invention; 

Fig. 2A is a view of a prior-art high-resolution bitmap for the letter "m"; 

Fig. 2B is a view of a prior-art bitmap of the letter "m" that has been stretched and aligned with a coarse grid such 
that when it is displayed on a black and white output device it will appear to have balanced stem widths; 
Fig. 2C illustrates the letter "m" rendered in a high-resolution bitmap; 
45 Fig. 2D illustrates the unbalanced stem widths that result in providing an anti-aliased version of the bitmap of Fig 

2C; 

Fig. 3 A is a flow-diagram of a method for creating anti-aliased characters with balanced stem widths in accordance 
with the present invention; 

Fig. 3B shows the relationship between a device grid and alignment grids; 
so Fig. 4 is an illustration of the "RECEIVE CALL FROM CLIENT" step of Fig. 3A; 

Fig. 5 is a flow-diagram of the "ALIGN STEMS" step of Fig. 3A; 

Fig. 6 illustrates the "ROUND STEM WIDTH TO COARSE GRID" and "CENTER STEM TO COARSE GRID" steps 
of Fig. 5; 

Fig. 7 illustrates the "ROUND STEM WIDTH TO HIGH-RESOLUTION GRID" and "ALIGN LEFT/BOTTOM AND 
55 TOP/RIGHT TO ALIGNMENT GRID" steps of Fig. 5; 

Fig. 8A, 8B, 8C, and 8D are used to illustrate a first example of the method of the present invention. 



BNSDOCID: <EP 1077445A2J_> 



EP 1 077 445 A2 

Detailed Description 

[0028] The present invention preferably includes processes executing ('running*') on a computer system such as 
the computer system 1 0 illustrated in Fig. 1 . However, as will be well appreciated by those skilled in the art, the proc- 
5 esses and apparatuses described herein can also be implemented by hardware or firmware equivalents. For example, 
many font rendering and other display processes are embedded in application specific integrated circuits (ASICs), as 
is well known to those skilled in the art. 

[0029] Figs 1 and 2A-2D were discussed relative to the prior art. In Fig. 3A ; a process 300 in accordance with the 
present invention for device dependent rendering to create anti-alias characters on a computer output device begins at 
w 302 and, in a step 304, by receiving device specific information for the computer output device. The device specific infor- 
mation can include geometry data and color data. 

[0030] The geometry data can include sub-pixel order and physical geometry information. The physical geometry 
defines the arrangement of sub-pixels for the computer output device, e.g., a horizontal row of sub-pixels. The sub-pixel 
order defines the arrangement of the particular sub-pixels in the physical geometry, e.g., a red sub-pixel, next to a green 

15 sub-pixel, next to a blue sub-pixel for each pixel in an RGB output device. Other output configurations are possible 
including GBR, GRB, BRG, BGR and RBG configurations. The physical geometry for an output device can be a row of 
color bars in one dimension, for example a horizontal row of color bars. Other arrangements include a closely packed 
arrangement. Methods for determining the geometry data are described in greater detail in co-pending patent applica- 
tion entitled "Device Specific Color Intensity Settings and Sub-Pixel Geometry" to Terence Dowling et. al., assigned to 

20 Adobe Systems Corporation of San Jose, California, filed on August 19, 1999, the contents of which are expressly 
incorporated herein by reference. 

[0031] The color data can be of the form of device specific intensity data for the computer output device. The device 
specific intensity data can be of the form of a mathematical function that defines a mapping from idealized intensity val- 
ues for a pixel to device specific intensity values. The mapping is used in the down sampling process for determining 
25 the intensity setting for a pixel in device space based on the number of pixels in the high resolution bitmap that are 
turned "on" when rendering the character. The rendering process is described in greater detail below. Methods for 
determining the color data are described in greater detail in co-pending patent application entitled "Device Specific 
Color Intensity Settings and Sub-Pixel Geometry" 

[0032] A call is received from a client with a character pointer, size, number of greyscales, and policy (306). As used 
30 herein, a "client" is an application program, utility, or other process that is requesting a high-resolution bitmap that can 
be further processed and displayed on an output device. For example, a client might be a word processing program. 
Alternatively, the client might be part of a greater "renderer." 

[0033] Hint data is evaluated for the character and a center for each stem is located (308). Hinting is used in ren- 
dering the character to avoid character distortions. Hinting is discussed in more detail below in the rendering step. 

35 [0034] For each stem, the center of the stem is translated onto each of a series of alignment grids (310). The 
"device grid' as used herein, is a grid of pixel locations that maps to the output device space and is often referred to as 
the course grid. The "fine grid", as used herein, is a grid of samples that has a resolution that is higher than that of the 
device grid. Associated with each fine grid is a series of alignment grids. The alignment grids are of the same resolution 
as the fine grid, yet have pixel boundaries that have been shifted by one sub-pixel position. After the selection of an 

40 appropriate alignment grid, the character is initially rendered to the resolution of the fine grid as described in greater 
detail below. 

[0035] Referring to Figure 3B a series of alignment grids and a device grid are shown. Alignment grid 380 includes 
a plurality of cells 382 that include a plurality of pixels 384. Each cell 382 maps directly to a single pixel in device grid 
392. Each device pixel 393 in device grid 392, is defined by a series of sub-pixels 394, arranged in a geometry. Align- 
45 ment grid 386 includes a plurality of cells 387 that include a plurality of pixels 388. Each cell in alignment grid 386 maps 
to a single "composite pixel" located in device grid 392. A "composite pixel", as used herein, refers to a series of adja- 
cent sub-pixels, that in aggregate form a pixel, yet are not grouped together to form a device pixel in device grid 392. 
For example, sub-pixels 394-2, 394-3 and 394-4, that belong to device pixels 393-1 , 393-1 and 393-2 respectively, form 
composite pixel 395. 

so [0036] The mapping of alignment grid 386 to device grid 392 is similar to the mapping of alignment grid 380 to 
device grid 392, but shifted by one sub-pixel. Similarly, alignment grid 389 includes cells 390 that include a plurality of 
pixels 391 . Each cell in alignment grid 389 maps to a single "composite pixel" 395 located in device grid 392. 
[0037] Referring again to Fig. 3A, an ideal location for the center of each stem is computed for each alignment grid 
(312). The ideal location data is compared and a best alignment grid is selected (314). More specifically, an alignment 

55 grid is selected from the set of alignment grids based on the location of the center of the stem to a sub-pixel boundary 
of the device grid (which corresponds to a pixel boundary of one of the alignment grids). The alignment grid selected is 
the grid having a pixel boundary that is closest to the ideal location of the center of the stem. 

[0038] In one implementation, the best alignment grid is selected as follows. Every normal stem hint defines two 
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edges in the character space coordinate system. The center of the hint (a value half way between the two edges) is 
used to determine position for alignment. The stem width (distance between edges) is compared with one or more 
standard widths (specified by the font program as StdVW, StdHW, StemSnapH, StemSnapV). If the value is close 
enough to the standard the standard width is used, otherwise the stem width is used. The width obtained is converted 

5 to device pixels using the provided coordinate transformation and the result is rounded to the nearest whole number 
representing the device grid size. This will yield a result of 0, 1 , 2, 3, ... device pixels. If the number is zero or odd then 
the preferred alignment is a pixel (or sub-pixel) center. If the result is even, the preferred alignment is on the boundary 
between pixels (or sub-pixels). With the center position and alignment rule (the pixel center or pixel edge), the device 
distance to the nearest alignment grid of each phase can be computed. This process is repeated for every stem. When 

w all of these distances for each stem and alignment grid phase are available, the alignment grid phase with the smallest 
"error" (that is, difference between the "ideal" stem center locations and those imposed by grid alignment with the 
selected alignment grid phase) can be determined. "Small," as used herein, may be defined as either the smallest sum 
of errors (in absolute value) or the smallest maximum error. 

[0039] Referring again to Fig. 3A, the character is rendered to produce a high resolution bit map of the character 
is including aligning the character to the selected alignment grid (316). Typically, the character is rendered at three or 
more times the output resolution. Hinting is used in rendering the character to avoid character distortions. More specif- 
ically, hint data is evaluated for each character to locate the horizontal and vertical sterns for the character and the posi- 
tion and width of each. For each stem, the stem width is determined. The stem width is compared to a standard stem 
width. If the stem width is close to the standard width, then width of the stem is set to be the standard stem width. The 
20 standard width is a multiple of the pixel width (in device space). If the width determined is not a multiple of a pixel width, 
the stem is stretched or contracted to be a multiple of a pixel width. 

[0040] Each stem is aligned to the selected alignment grid based on the policy information. As will be discussed in 
greater detail later, this policy includes whether the character should be "hard-edged" or "soft-edged", which may some- 
times be referred to as "hard" or "soft" policies, respectively. This policy can be selected dynamically by the renderer, 
25 the client, or can be predetermined by the creator of the render. Alignment is discussed in greater detail below in asso- 
ciation with Fig. 6. 

[0041] A mapping is determined from each ideal pixel in the selected alignment grid to a respective device pixel in 
the device grid (320). The geometry data is retrieved and used in the mapping. More specifically, a cell of pixels in the 
alignment grid is mapped to either a device pixel or a composite pixel in the device grid (depending on the alignment 
30 grid selected). In one implementation, the mapping from the alignment grid to device grid is defined mathematically, 
where 

P = ideal x hint x font point size x device resolution; 

35 where 

P= the device pixel location in the device grid, 
ideal = to the ideal pixel location in the alignment grid, 
hint = hint stretching or shrinking factor, and 
40 device resolution is the resolution of the output device in device space. 

[0042] Once mapped, an device specific intensity value is calculated for each pixel location in the device grid (322). 
The device specific intensity values is calculated from the ideal intensity value for a given cell of the alignment grid. The 
ideal intensity setting for a device pixel is calculated by in a straightforward fashion. In one implementation, the ideal 

45 intensity value is calculated as described in the co-pending application entitled "Method and Apparatus for Rendering 
Characters \ Alternatively, the ideal intensity value can be calculated (and scaled) as is described in United States Pat- 
ent numbers, 929, 866 entitled "Anti-aliasing Small Characters" to David Arnold, assigned to Adobe Systems, Inc. of 
San Jose, California, the contents of which are expressly incorporated herein by reference. After an ideal intensity value 
is determined, the color data is retrieved. The color data defines a mapping from idealized intensity values to device 

so specific intensity values. The mapping is used to determine the intensity setting for a pixel ( or composite pixel) in device 
space. Thereafter the process ends. 

[0043] Fig. 4 is used to illustrate step 306 of Fig. 3 in greater detail. More particularly, an enhanced font renderer 
88 of the present invention receives a call 89 from a client 90 which includes a character pointer, a character size, the 
number of greyscales, and the policy. The renderer 88 creates a call 91 to a parsed font program 92 which returns a 
55 character program (to create the font outline of the character), font values, and font family values as illustrated at 93. 
The enhanced font renderer 88 then passes a high-resolution bitmap as illustrated at 95 to the client 90, which does the 
greyscale rendering and which sends a low resolution pixel map 96 to an output image device 94. 
[0044] As explained above, the client 90 can be any application program, utility, or other computer-implemented 
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process capable of requesting that a character be displayed on the output device 94. The parsed font program is pref- 
erably a font program such as Adobe-type I format available from Adobe Systems, Inc. of San Jose, California. A com- 
plete description of the use and operation of a parsed font program 92 can be found in the "Black Book", supra. 
[0045] It is readily apparent to those skilled irr the art and with knowledge of the contents of the "Black Book" how 
5 clients such as client 90 make calls to Tenderers, and receive high-resolution bitmaps back from the Tenderers, and fur- 
ther, how client 90 can produce a pixel map from the high-resolution bitmap for the output device 94. The use of a 
parsed font program 92 is also well known to those skilled in the art, along with the receipt of calls from a rendered and 
the providing of the character program, font values, and font family values. 

[0046] In Fig. 5, step 318 of Fig. 3A is illustrated in greater detail. More particularly, process step 318 begins at 98 
w and, in a step 1 00, the current font matrix and stem properties are received from the parsed font program 92. Details of 
the operation are again explained in the "Black Book." Next, the stem properties are transformed with the matrix to 
obtain alignment grid locations of the stem edges and stem widths in a step 1 02. 

[0047] In a step 104, it is determined whether the policy is a "hard-edge" or a "soft-edge" policy. A hard-edge or 
"hard" policy is one wherein vertical and horizontal stems are made perfectly black, i.e., greyscale is not used. In a hard- 
is edge policy, only curves and diagonals are subject to greyscale-type anti-aliasing techniques. In contrast, soft-edge or 
"soft" policies permit anti-aliasing of the horizontal and vertical stems. 

[0048] Whether hard-edge or soft-edge policies are adopted may be chosen by the client or left to the discretion of 
the renderer. Hard-edge policies tend to make sharper, darker stems, but may suffer from some of the quantization 
effects noted earlier. Soft-edge policies appear to be smoother, but may seem "fuzzy" to some viewers. 
20 [0049] If a hard-edge policy is chosen, step 1 06 rounds the stem width to an integral coarse grid. By "integral" it is 
meant an integral multiple of a cell width is chosen, i.e. 1, 2, 3, etc. multiples of the cell width. Next, in a step 108, the 
stem is centered to the alignment grid and the process is completed at 1 10. 

[0050] If a soft policy is selected as detected by step 104, a step 112 rounds the stem width to an integral high-res- 
olution grid, and then a decision step 1 1 4 determines whether the stem is a "ghost" stem. The term "integral" is used in 
25 a similar fashion here to mean integer multiples of the high-resolution grid pixels, i.e. 1 , 2, 3, etc. multiples of the high- 
resolution grid pixels. "Ghost" stems are discussed in the aforementioned "Black Book' and, briefly, are stems that have 
only one edge to control. 

[0051] If the stems are not ghost stems, a step 1 1 6 determines the proximity of the stem to a pixel boundary of the 
grid and aligns the stem to a pixel boundary of the alignment grid based on this proximity. 

30 [0052] If step 1 1 4 determines that the stem is a ghost stem, a decision step 1 22 determines the type of ghost stem. 
If it is a left/bottom ghost stem, it is aligned with a left/bottom of the alignment grid cell based on this ghost information. 
If it is a top/right ghost stem, it aligns to the top/right of the coarse grid cell based on this ghost information in the step 
126. Note that this adjustment is not proximity determined as in step 1 16, but rather directed by the "ghost" hint itself. 
After the completion of any of steps 118, 120, 124, and 126, the process is completed as illustrated at 1 10. 

35 [0053] In Fig. 6, an illustration is made to help explain the hard policy steps 1 06 and 1 08 of Fig. 6. In Fig. 6, a coarse 
grid 128 will be assumed for the purposes of example to have cells 130 that are square and which are four pixels on 
each side. An "ideal" spot 132 is shown to be partially within cell 130a, and also partially within an adjacent cell 130b. 
The center of this ideal spot 1 32 is shown at 1 34. 

[0054] At this point it should be noted that there are some device-dependent and some designer-dependent deci- 
de sions that can be made. For example, the decision as to how to align the ideal spot 132 with the coarse grid 128 very 
much depends upon the type of output device used and upon designer decisions. For example, most first generation 
personal computer printers use the "Canon" print engines manufactured by Canon, Inc. of Japan. With these fist gen- 
eration printers, a round pixel is printed that completely covers the cell of the coarse grid, i.e. the round pixel has a diam- 
eter that is about equal to a diagonal of the cell of the grid. 
45 [0055] In recent years, a number of new types of print engines have been developed. For example, a "Xerox" 
engine manufactured by Xerox, Inc. of the United States produces a pixel having four concave sides such that the pixel 
fits entirely within the cell of the coarse grid. As a result, three pixels produced by a Canon engine can cover 3.8 cells 
of the coarse grid, while four pixels produced by a Xerox engine can cover 3.7 cells of the coarse grid. 
[0056] With the foregoing explanation in mind, a step 1 08 of Fig. 5 will be discussed as if an output device can pro- 
so duce a perfectly square pixel corresponding to the square cell 30 of the coarse grid 1 28, it being understood that this is 
only an approximation of the reality. As seen in Fig. 6, if the ideal spot 132 is less than 6 pixels (■6-" pixels), it will be 
shrunk to four pixels in width and aligned with the cell 1 30a. However, if the spot 1 32 is greater than 6 pixels ("6+" pix- 
els), it will be increased to 8 pixels in width and will be caused to fill both cells 130a and 130b. In the first instance, the 
center of the spot 132' is at 134' (i.e. the center of cell 138), and in the other instance the spot 132" has a center 134" 
55 which is at the interface between cells 130a and 130b. In this way, the spot 132 is aligned to the coarse grid 128 such 
that the balance of stem weights is preserved. 

[0057] In Fig. 7, the soft-edge policy is illustrated. More particularly, Fig. 7 illustrates the steps 112, 118, 120, 124, 
and 126 of Fig. 5. As seen in Fig. 7, an ideal spot 136 has a center 138 and is associated with a coarse grid 140 and a 
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high-resolution grid 142. As before, the high-resolution grid is shown in only one of the cells 144 of the coarse grid 140 
so as not to confuse the drawings, although it will be appreciated that the high-resolution grid 142 is associated with all 
the cells of the coarse grid 140. 

[0058] In accordance with the "soft-edge" policy-step 1 12 first rounds the stem width to an integral high-resolution 
5 grid 142. In this instance, a side of a high-resolution grid pixel is 1/4 of a side of a cell 144. Therefore, the width of the 
stem 134 is rounded to the nearest 1/4 of a alignment grid cell in a step 112. Next, it is determined which cells of the 
alignment grid 140 the rounded stem width is to be aligned with. This is the purpose of steps 1 14, 1 16, and 122. When 
the proper alignment grid cell is found, the rounded stem is aligned accordingly. 

[0059] In this example, the spot 136 is somewhat centered within a cell 144a and 144b. If it is determined that the 
w rounded stem is to be aligned to the left cell, it is moved as indicated to the position 136' such that it completely fills the 
cell 144a and overlaps partially the cell 144b. if, on the other hand, it is to be aligned with the right cell, it is moved so 
that it completely fills the cell 144b and partially overlaps with the cell 144a. 

[0060] By analogy, if the stem 136 is only partially overlapping the cell in the vertical direction, it can be aligned to 
the top or bottom of the cell of the coarse grid in a similar fashion. Furthermore, if it only partially overlaps a cell both in 
15 the vertical and horizontal direction, it can be caused to move to align with the cell of the alignment grid both in the 
left/bottom and top/right directions. Therefore, both horizontal and vertical stems can be handled by the process and 
apparatus of the present invention. 

[0061] The foregoing descriptions and illustrations describe the basic process and apparatus of the present inven- 
tion. As mentioned previously, the process of the present invention is preferably practiced on a general-purpose com- 
20 puter system to provide images on an output device such as a video monitor, a video projection system, or a 
continuous-tone printer. The process and apparatus of the present invention will be further discussed in terms of an 
illustrative example. 

Example 1- The Lower Case Letter "m" 

25 

[0062] In Fig. 8A, the font outline 148 of the letter "m" is shown superimposed over a coarse grid 146. A high-reso- 
lution bitmap 1 50 is created from this font outline 1 48. It will be noted that the high-resolution bitmap 1 50 is aligned with 
a high-resolution grid 152. 

[0063] Fig. 8B illustrates the pixel map as created in accordance with the "soft-edge" policy of the present invention. 
30 The high-resolution bitmap 150 is first rounded with respect to high-resolution grid 152, and is then aligned with the 
coarse grid 146 as described above. Then the pixel map 154 is created by this rounded and aligned bitmap to provide 
the appropriate greyscale data for the output device. As can be seen, the stems 156a, 156b, and 156c are all of the 
same width and have about the same pixel density. This will provide an anti-aliased output, while still preserving stem 
width balance. 

35 [0064] The "hard-edge" policy will be described with reference to Fig. 8C. In this instance, the data as illustrated in 
Fig. 8A is "stretched" such that each of the stems 158a, 158b, and 158c have the width of a cell 160 of the coarse grid 
148. This is in accordance with steps 106 and 108 of Fig. 5. Next, the "stretched" bitmap 160 of Fig. 8C is converted to 
the greyscale pixel map 1 64 of Fig. 8D. Note, once again, that the stems 1 66a, 1 66b, and 1 66c of the pixel map 1 64 are 
of the same width and, substantially of the same density. This allows the letter "m" to be anti-aliased while preserving 

40 its stem weight balance. 

[0065] While this invention has been described in terms of several preferred embodiments, there are alterations, 
permutations, and equivalents which fall within the scope of this invention. It should also be noted that there are may 
alternative ways of implementing both the process and apparatus of the present invention, and that certain concepts 
were introduced for the purpose of instruction and clarity. 

45 [0066] For example, as described previously, coarse, alignment and high-resolution grids are preferably not actually 
"constructed" within the process but, rather, are used herein to explain the concepts of the present invention. Also, as 
will be appreciated by those skilled in the art, the order of steps can often be changed, and certain steps have been 
simplified for the purpose of clarity. For example, the step of "rendering a high-resolution bitmap" is preferably imple- 
mented by first developing a high-resolution "hintmap", providing adjustments to the hintmap, and then rendering the 

so actual pixels of the high-resolution bitmap. The "hintmap" is simply a high-resolution representation of the grid-fit align- 
ment zones of the character, as will be appreciated by those skilled in the art. Alternatively, the high-resolution bitmap 
rendering step can be the single step described above. The geometry can be two dimensional, and as such, the 
increase in resolution can be realized in more than one dimension. 

[0067] It is therefore intended that the following appended claims be interpreted as including all such alterations, 
55 permutations, and equivalents as fall within the true spirit and scope of the present invention. 
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Claims 

1. A computer-implemented method for processing a character for display on a raster output device where the output 
device has a resolution and a set of pixels defining a device grid, the method comprising: 

5 

evaluating a plurality of alignment grids and selecting a best alignment grid for a stem of the character where 
the plurality of alignment grids from a set of grids, each alignment grid in the set being similar to the device grid 
but shifted by a phase difference equal to a sub-pixel dimension; 

rendering the character at a resolution higher than the resolution of the output device including aligning the 
w stem using the selected alignment grid to a sub-pixel boundary; and 

down sampling the rendered character to the resolution of the output device. 

2. The method of claim 1, wherein the character being created at a type size by a font having font metrics including 
hinting information defining a center of a stem and where the step of evaluating includes laying down the character 

15 and determining an alignment grid that best aligns the center of the stem to a sub-pixel boundary. 

3. The method of claim 1 , further including 

receiving sub-pixel geometry information for the output device defining a geometry of the addressable sub-pix- 
20 els for each pixel of the output device; and 

where the step of aligning the character includes using the sub-pixel geometry information to determine which 
sub-pixels of which pixels to illuminate when the character is not aligned to a pixel boundary. 

4. The method of claim 1 , wherein the step of down sampling includes 

25 

receiving device specific data derived specifically for the output device where the device specific data includes 
a plurality of functions, one for each color plane used by the output device; and 

determining an intensity for each sub-pixel of a pixel in the selected alignment grid using the device specific 
data to derive intensity data specifically for the output device. 

30 

5. The method of claim 1 where the sub-pixel dimension is a sub-pixel width. 

6. The method of claim 1 where the sub-pixel dimension is a sub-pixel height. 

35 7. The method of claim 1 where the sub-pixel dimension is a sub-pixel height and width. 

8. A computer-implemented method for processing a character for display on a raster output device having an reso- 
lution defined by a set of output pixel positions, the method comprising: 

40 aligning a stem of the character to a best sub-pixel boundary; 

rendering the character at a resolution higher than the resolution of the raster output device; and 
down sampling the aligned character to the raster output device resolution. 

45 



50 



55 



BNSDOCID: <EP 1077445A2J_> 



10 



CPU 



ROM 



EP 1 077 445 A2 





VIDEO 




DISPLAY 





20 



PRINTER 



- ^ T^- :v r?f 



RAM 



I/O 



i 



DISK 
STORAGE 



KEYBOARD 
^f4 



FIG..1 

(PRIOR ART) 



BNSDOCID: <EP 1077445A2J_> 



10 



EP 1 077 445 A2 




BNSDOCID: <EP 1077445A2J_> 



11 



EP 1 077 445 A2 




12 



BNSDOCID: <EP 1077445A2_L> 



EP 1 077 445 A2 




13 

BNSDOCID: <EP 1 077445 A2J_> 



EP 1 077 445 A2 




14 



BNSDOCID: <EP 1077445 A2_l_> 



EP 1 077 445 A2 



302 

X 



Start 



304 



306 



I 



Receive device 
specific information 
(geometry and 
color data) 

i 



Receive call from 
client 



308 



I 



Evaluate hint data 
and locate center 
of each stem 



310 



i 



312 



For each stem, 
\ translate the center 
l of the stem onto a 
series of alignment 
grids 



\ 



314 



Compute an ideal 
location for the 
center of each 
stem for each 
alignment grid 

i 



Select best 
alignment grid 



316 



\ 



Render character 
including aligning 
each stem to the 
selected alignment 
grid 



FIG. 3a 



1 



320 



Determine 
mapping from 
alignment grid to 
device grid 



v 



Calculate a device 
specific intensity 
value for each pixel 



c 



322 



End 



3 



15 



BNSDOCID: <EP_ 



_1077445A2_I_> 



EP 1 077 445 A2 




EP 1 077 445 A2 



LOW 
RESOLUTION 
BITMAP 



90 



C 




CHAR PTR SIZE. 
# GRAY. POLICY 




HIGH 
RESOLUTION 
BITMAP INFO 



ENHANCED 
GRAYSCALE 
FONT RENDS RER 



r9S 

f PARSED FONfN 
PROGRAM J 




CHAR PROGRAM, 
FONT VALUES. 
FONT FAMILY VALUES 



BNSDOCID: <EP 1077445A2_I_> 



17 



EP 1 077 445 A2 



F/G-5 



f START Jl 



98 



80 



rioo 



RECEIVE CURRENT FONT MATRIX 
AND STEM PROPERTIES 



I 



ri02 



TRANSFORM STEM PROPERTIES WITH MATRIX 
TO OBTAIN DEVICE GRIO LOCATION OF 
STEM EDGES AND STEM WIDTH 



104 



HARD 



POLICY? 



FIND CENTER AND 
ROUNO STEM 
WIDTH TO INTEGRAL 
(M-ifc(J»Nf GRIO 




■ 

■ r 1 " 


CENTER 


STEM TO 1 
* GRIO i 



rU2 



SOFT. 


ROUNO 


STEM WIDTH 




TO AN INTEGER 




RNE GRID 




ALIGN 
LEFT/BOTTOM TO 

LEFT/BOTTOM 
At4f— -er GRID 
EDGE BASED ON 
PROXIMITY 



ALIGN 
LEFT/BOTTOM TO 
.LEFT/BOTTOM 

EDGE BASED ON 
GHOST INFO 



120 



ALIGN TOP/RIGHT 
TO TOP/RIGHT 

A<4tA"M6"irGRID 

EDGE BASED ON 
PROXIMITY 




TOP/ 
RIGHT 



r126 



ALIGN TOP/RIGHT 
TO TOP/RIGHT 
A wt-«fi«r grid 

EDGE BASED ON 
GHOST INFO 



18 



BNSDOCID. <EP 1077445A2_I_> 



EP 1 077 445 A2 



4 PIXELS 



128 



■ft 



130b 



128 



-132 



6~ PIXEL 



130a - 




A3Z 












134'- 










FIG- L 



144S 



= > 



140 



144b 



■136 



LEFT 



RIGHT 



144a 




■144b 











144m- 


7 C 


H 













F/G._ 7 



19 

BNSDOCID: <EP. 1077445A2_L> 



EP 1 077 445 A2 




20 

BNSDOCID: <EP 1077445A2J_> 



EP 1 077 445 A2 



• «fl « CM 




I 



BNSDOCID: <EP 1 077445 A2_l_> 



21 



EP 1 077 445 A2 




22 

BNSDOCID: <EP 1077445A2_I_> 



EP 1 077 445 A2 



«n ^ « cv 




«0 «T 0) M ^ O 



BNSDOCID: <EP 1077445A2J_> 



23 



THIS fWGE BLANK (uspto) 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 




I 



(12) 



(ID EP 1 077 445 A3 

EUROPEAN PATENT APPLICATION 



(88) Date of publication A3: 

26.09.2001 Bulletin 2001/39 

(43) Date of publication A2: 

21.02.2001 Bulletin 2001/08 

(21 ) Application number: 00306945.7 

(22) Date of filing: 14.08.2000 



(51) mtci7: G09G 5/28, G09G 5/24 



(84) Designated Contracting States: 

AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 
MC NL PT SE 

Designated Extension States: 
AL LT LV MK RO SI 

(30) Priority: 19.08.1999 US 378237 

(71) Applicant: Adobe Systems, Inc. 
San Jose, California 95110 (US) 



(72) Inventors: 

• Dowling, Terence S. 

San Jose, California 95138-2226 (US) 

♦ Hall, Jeremy A. 

San Jose, California 95120-3358 (US) 

(74) Representative: Wombwell, Francis 
Potts, Kerr & Co. 
15, Hamilton Square 
Birkenhead Merseyside L41 6BR (GB) 



CO 
< 

in 

O 



CL 
LU 



(54) Device dependent rendering of characters 

(57) A method for creating anti-aliased characters 
on a computer output device includes the steps of gen- 
erating a call from a client process for a character to be 
rendered, selecting a best alignment grid from a set of 
alignment grids associated with the device grid, render- 
ing the character at a high resolution, and aligning stems 
of the character with an alignment grid corresponding to 
the resolution of an output device. The step of aligning 
the high resolution rendered stems to the alignment grid 
provides for an anti-aliased output with balanced stems. 



302 



FIG. 3a 




320 



322 



Printed by Jouve, 7S001 PARJS (FR) 



BNSDOCID: <EP 1077445A3_I_> 



EP 1 077 445 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



A pp I cat ion Number 

EP 00 30 6945 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document wfth indication, where appropriate. 
ol relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLCATIOJ (fotCi.7) 



EP 0 772 144 A (ADOBE SYSTEMS INC) 

7 May 1997 (1997-05-07) 

* abstract * 

* column 2, line 13 - line 49; figure 2A * 

* column 3, line 4 - column 4, line 30; 
figures 2B- 3C * 

* column 5, 1 ine 15 - column 6, line 15 * 

* column 8, line 19 - line 46; figure 4 * 

* column 9, line 33 - column 10, line 12; 
figure 6 * 

* column 10, line 31 - line 50; figure 7 * 

* column 11, line 1 - column 12, line 35; 
figures 8,9 * 

US 5 910 805 A (HASCHART ROBERT J ET AL) 

8 June 1999 (1999-06-08) 

* abstract * 

* column 3, line 27 - line 47 * 
line 43 - column 8, line 59; 



1-8 



G09G5/28 
G09G5/24 



1-8 



* column 6, 
figures 1-6 

* column 9, 
figure 7 * 

* column 11 



line 54 - column 10, line 42; 



figures 10-13 * 



line 65 - column 15, line 14; 



The present search report has been drawn up for ah claims 



TECHNICAL FIELDS 

(lnt.CI.7) 



G09G 
G06T 



Race o< sea*ch 

THE HAGUE 



Dais ol complain ol the s*arc*i 

2 August 2001 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant st tafcen 4 one 
S Y : particularly relevant ft combined wrth another 
5 document of the same category 

- A tecnnoioQteaJ bactqgrounti 
O : non-written doctosure 
P intermediate document 



Examinei 

Corsi, F 



T : theory or principle undertying the invention 
E : eartier paten! document, but published on. or 

alter the fthng date 
O : document cited In the application 
L : document cited for other reasons 



& . mem Der ot me s 
document 



i patent tamiiy. corresponding 



2 



BNSDOCID: <EP 1077445A3J_> 



EP 1 077 445 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Numtef 

EP 00 30 6945 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with Indication, where appropriate, 
of relevant passages 



Relevant 
to daim 



CLASSIFICATION OF THE 
APPLICATION (lntCL7) 



EP 0 693 740 A (MICROSOFT CORP) 
24 January 1996 (1996-01-24) 
* abstract * 
column 1, line 5 - line 12 * 
column 4, line 18 - line 51 * 
column 7, line 19 - column 8, line 59 * 
column 9 t line IB - line 29 * 
column 11, line 23 - column 12, line 12; 

column 13, line 27 - line 49; figure 4 * 

column 14, line 15 - line 27; figures 
6 * 

column 15, line 31 



* 
* 

figure 1 
5 

* 



column 16, line 38 
column 18, line 14 - column 19, line 30 



column 20, line 3 - line 38 * 
column 21, line 26 - line 42 * 
column 23, line 10 - column 24, line 43; 
figures 7,8; table 1 * 

EP 0 435 391 A (PHILIPS NV) 
3 July 1991 (1991-07-03) 
abstract * 

* column 1, Hne 53 - column 2, line 40; 
figure 5 * 

* column 3, line 55 - column 5, line 6; 
figures 1,2* 



US 5 132 674 A (B0TT0RF SCOTT A) 
21 July 1992 (1992-07-21) 

abstract * 
* column 1, line 23 - line 60 * 

column 2, line 66 - column 3, line 
figure 2 * 



21; 



-/- 



The present search report has been drawn up tor all claims 



1-8 



TECHNICAL FIELDS 
SEARCHED (lntCl-7) 



Placo of search 

THE HAGUE 



Cm'« ct ccnipl«tKjn of tht» Mate 

2 August 2001 



Examine > 

Corsl, F 



1 

iX 

o 

Li- 

? 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant if taken alone 

Y : particularly relevant It combined with another 

document of the same category 
A : technological bactorjound 
O non-wrtten dfectosure 
P imerrnecltaie document 



T theory or prince to jndertying the invention 
E : earlier patent document, but published on. or 

after the filing date 
D : document cied m the application 
L : document cried for other reasons 



Jl : member of me same patent family, corresponding 
document 



3 



BNSDOCID: <EP 1 077445A3_I_> 



EP 1 077 445 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 00 30 6945 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document wrth indication, where appropriate. 
of relevant passages 



EP 0 397 299 A (ADOBE SYSTEMS INC) 
14 November 1990 (1990-11-14) 

* abstract * 

* page 2, left-hand column, paragraph 1 • 
right-hand column, paragraph 2 * 

* column 1, line 15 - line 51 * 

* column 2, line 30 - column 3, line 55; 
figure 1 * 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (toLCi.7) 



1-8 



TECHNICAL FIELDS 
SEARCHED (It*. C 1.7) 



The present search report has been drawn up tor all darns 



Place ot saarcn 


Date ot compietcn of the search 




THE HAGUE 


2 August 2001 


Corsi, F 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant if taken alone 

Y : particularly relevant if combined with another 

document of the same category 
A : technological background 
O : non-wmtten 
P. 



T theory or principle underlying the invention 
E : earlier patent document, but published on. or 

after the filing date 
D : document cited in the application 
l. : document cited for other reasons 

& : member of the same patent I amity corresponding 
document 



4 



BNSDOCID: <EP 1077445A3_I_> 



EP 1 077 445 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 

ON EUROPEAN PATENT APPLICATION NO. EP 00 30 6945 



This annex Hsts the patent famity members relating to me patent documents cited in the above-mentioned Eurocean search report 
The members are as contained in the European Patent Office EDP file on p 
The European Patent Office is in no way liable tor mesa particulars wfiich are merely given to- me purpose of information. 

02-08-2001 



Patent document 
cited in search report 


Publication 
date 


Patent family 
member(s) 


Publication 
date 



EP 0772144 



07-05-1997 



US 
CA 
JP 



5943063 A 
2188512 A 
10268858 A 



US 5910805 



EP 0693740 



A 
A 



08-06-1999 



NONE 



24-01-1996 



EP 0435391 



03-07-1991 



US 5132674 



21-07-1992 



EP 0397299 



14-11-1990 



24-08-1999 
24-04-1997 
09-10-1998 



US 


5684510 


A 


04-11-1997 


DE 


69507917 


D 


01-04-1999 


DE 


69507917 


T 


14-10-1999 


DE 


69517605 


D 


27-07-2000 


DE 


69517605 


T 


15-02-2001 


EP 


0843283 


A 


20-05-1998 


JP 


3072250 


B 


31-07-2000 


JP 


8255254 


A 


01-10-1996 


JP 


3201788 


A 


03-09-1991 


DE 


69018217 


D 


04-05-1995 


DE 


69018217 


T 


02-11-1995 


HK 


194496 


A 


01-11-1996 


US 


5334996 


A 


02-08-1994 


EP 


0313332 


A 


26-04-1989 


US 


5050103 


A 


17-09-1991 


CA 


2016609 


A 


12-11-1990. 


DE 


69022109 


D 


12-10-1995 


DE 


69022109 


T 


15-02-1996 


JP 


2992698 


B 


20-12-1999 


JP 


3208093 


A 


11-09-1991 



o 



o 

& For more details about this annex : see Official Journal of me European Patent Office. No. 12/82 



5 



BNSDOCID: <EP 1077A45A3_I_> 



WIS RAGE BLANK (uspt©) 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



